Development of quality enterprise software, for example, software which is employed by large corporations to conduct operations, is a complicated task. Many organizations have evolved standardized processes for developing software in order to achieve consistency and predictability in their software development activities. This consistency and predictability effect how much time it takes to develop the software and how robust and reliable the software is.
Typically a software development process produces intermediate products or artifacts along the path to producing the finished software product. Production of these artifacts serves to provide a sense of direction to the software developers. The software developers are instructed what content and level of detail the artifacts are expected to contain. Creating the artifact according to these expectations compels the software developer to work through specific issues of the software development and hence defines a sequence and direction to the software development work. The artifacts serve as an excellent basis to share technical information among software developers, testers, and managers. Often the software development process employs reviews of the in-progress software development to decide whether the work has matured sufficiently to advance to the next stage in the software development cycle or whether more work is required. The artifacts capture the current maturity and completeness of software development and provide visibility into the status of the software development to reviewers.
A variety of names for software artifacts are employed by different companies. Often a given artifact name means different things to software development teams in different companies. Some of the typical artifacts are briefly described below.
Requirements documents define functional requirements that the finished software is expected to satisfy. Sometimes requirements are divided into high level or customer requirements and into low level, derived, or engineering requirements.
Use cases are brief textual descriptions of a business operation at a high level. They are intended to capture the nature of a single business operation from the view of the end user and not the view of the technologist developing the software.
Message sequence diagrams, also referred to as sequence diagrams, may be employed to capture inter-module or inter-application communication sessions. These diagrams indicate the participants in the communication session, the senders and the receivers of each communication, the content of each communication, and the sequence of the communications. The communications may be termed messages.
Interface documents define the interface between different modules, systems, or applications. Such documents may define the communication technology employed, for example, sockets, message queues, Java remote method invocation (RMI), transmission control protocol (TCP), and ethernet. They may define the structure of the information communicated in terms of bit sequences, byte sequences, and fields. They may define the valid values or valid range of values and the meanings of values which may be communicated. They may define a mandatory message sequence, or handshake, for establishing a communication link, for exchanging information, and for terminating the communication link. Sometimes these documents are called interface control documents (ICDs).
High level design documents (HLDs) and low level design documents (LLDs) are comprehensive documents which may contain any of the preceding information. Additionally, HLDs and LLDs typically provide a narrative text description of design which is not a normal part of the other artifacts. HLDs provide less detail than LLDs. The definition of what information belongs in a HLD versus what information belongs in a LLD differs from one software development organization to another. Some software development organizations produce only HLDs and no LLD. Some software development orgnaizations do not produce either HLDs or LLDs, but capture the information with other artifacts.
Software development tools have been created to aid software developers to develop software and to encourage them to follow and adhere to the software development process. These tools may provide editors for quick construction and revision of message sequence diagrams, interface documents, and other documents. These tools may perform rules checking between development artifacts, for example, to validate that the accepted software development process is adhered to, to discover shortcomings in a given artifact. Some software development tools may be sold or leased as off-the-shelf software from software vendors. These off-the-shelf software development tools may provide means to extend their capabilities and to customize their behavior to accommodate the needs of a specific software development organization. Some of these tools may be referred to as computer aided software engineering (CASE) tools.
Software development tools may impose specific structures on the information captured in the artifacts, and the structures may be different from one specific software development tool to another software development tool. An incompatibility between software artifacts produced using different software development tools may cause difficulties when modifying existing software. For example, if software which was developed using tool A now needs to be modified using tool B, the developer may need to manually translate the software artifacts associated with the software being modified from the structure associated with tool A to the structure associated with tool B. This incompatibility between software artifacts produced using different software development tools may cause similar problems when two intercommunicating systems are developed using different software development tools, which may happen when systems are developed by different branches of one company.